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Scope 

There  are  many  standards  available  to  the  telemetry  community  for  internetworking  systems 
together.  The  vast  majority  of  these  standards  apply  to  the  movement  of  data.  A  standard  is 
needed  to  define  the  data  itself.  However,  the  format  of  the  data  being  moved  is  closely  tied  to 
the  applications  that  source  and  sink  the  data.  This  project  will  focus  on  defining  a  structure(s) 
for  the  various  messages  required  within  a  data  acquisition  network. 

Background 

There  has  been  growing  interest  in  fast  commercial  busses  operating  via  network  concepts  for 
the  past  3  years.  The  Next  Generation  Instmmentation  Bus  (NexGenBus)  project,  through  a 
series  of  trade  studies,  identified  a  network-based  bus  -  Fibre  Channel  -  as  the  likely  candidate 
for  future  data  acquisition  systems.  Around  the  same  timeframe,  packetized  telemetry  methods 
were  being  investigated.  The  decision  was  to  use  the  CCSDS  standard  for  Packetized  Telemetry. 
Both  of  these  standards  are  being  adopted  by  the  new  release  of  the  IRIG  106  Telemetry 
Standards  (2001).  This  release  marks  a  milestone  in  that  it  contains  a  new  part  dedicated  to 
network  based  data  acquisition. 

Basis  for  Need 

Data  acquisition  networks  are  the  future  of  instrumentation  data  systems.  Fibre  Channel  (an 
ANSI  standard)  has  been  selected  as  the  next  generation  instrumentation  bus.  These  airborne 
data  acquisition  systems  will  be  using  network  protocols  to  move  the  data  around  the  test  article 
and  to  the  ground.  The  area  that  has  not  been  addressed  by  data  acquisition  networks  yet  is  the 
structure  of  the  data  it  is  moving. 

The  structure  of  a  message  is  highly  dependent  upon  the  type  of  data  it  contains.  A  calibration 
file  will  have  a  structure  different  from  an  executable  file.  Application  designers  construct  the 
file  format  based  on  the  type  of  data  and  how  that  data  will  be  used. 

A  network  approach  to  data  acquisition  provides  opportunities  to  acquire  data  using  advanced 
methods.  The  asynchronous  nature  of  these  networks  makes  it  easy  to  insert  new  messages  as 
the  test  conditions  change  (event  driven  data).  Data  acquisition  networks  also  allow  for 
increased  connectivity  from  testing  the  system  in  the  lab  to  remotely  programming  the  system  on 
the  flight-line.  To  take  advantage  of  these  opportunities  the  message  structure  used  in  data 
acquisition  systems  needs  to  be  judiciously  defined. 

Deficiencies  with  Current  Message  Definitions 

The  biggest  deficiency  with  current  message  definitions  is  simply  there  aren’t  any  developed 
around  networked  test  and  evaluation  (T&E)  data.  With  current  systems,  a  central  encoder 
gathers  all  of  the  digitized  samples  and  creates  a  fixed  set  of  messages  (PCM  minor  frames). 
Each  message  has  an  ID  number  (subframe  ID  or  SFID)  that  distinguishes  it  from  the  others 
(shown  in  Figure  1).  After  each  message  has  been  sent  in  order,  the  process  starts  over  at  the 
beginning.  The  number  and  content  of  the  messages  are  typically  fixed  for  a  given  session. 
Information  concerning  the  processing  of  the  data  is  handled  extrinsically  and  is  unique  to  each 
session. 
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Networked  data  systems  allow  a  dynamic  approach  to  data  management  that  traditional  fixed 
frames  cannot  easily  support.  Multiple  message  types  can  be  defined  and  transported  at  any 
given  time.  The  rest  of  the  system  can  be  producing  data  messages  while  one  or  more  units  are 
being  programmed.  Individual  units  can  change  their  output  data  messages  through  external 
commands  or  preprogrammed  data  thresholds.  All  of  this  is  easily  achievable  when  a  single 
message  structure  is  defined  to  handle  multiple  data  types  coupled  with  an  asynchronous 
network  bus. 

Alternatives 

The  identified  alternatives  are  discussed  below. 

Don’t  define  a  standard 

As  with  most  situations,  doing  nothing  is  always  an  option.  Vendors  would  define  a  message 
structure  that  works  best  from  their  point  of  view  and  by  definition  for  their  products.  With 
homogeneous  systems  this  isn’t  necessarily  a  crisis.  The  ground  stations  will  have  specific 
decoding  algorithms  for  each  vendor.  For  each  test,  the  instrumentation  engineer  would  identify 
the  vendor/message  type.  This  is  not  an  ideal  situation,  but  certainly  a  workable  one. 

One  of  the  goals  of  standardizing  the  various  interfaces  within  a  data  acquisition  system  is  to 
make  the  components  interoperable.  Much  like  buying  stereo  or  computer  equipment,  a  user 
should  be  able  to  buy  a  bus  monitor  from  one  vendor,  a  thermocouple  unit  from  another  vendor, 
and  a  bridge  conditioner  from  a  third.  All  three  units  should  work  in  the  same  system 
transferring  their  data  messages  to  the  transmitter  or  recorder.  The  ground  station  would  need  to 
identify  each  vendor’s  message  and  apply  the  appropriate  decoding  algorithm.  Without 
minimum  standards  as  to  how  to  distinguish  one  vendor’s  message  from  another,  interoperability 
of  components  becomes  useless.  Most  users  would  prefer  to  buy  a  complete  system  from  a 
single  vendor.  However,  the  real-world  scenario  is  they  are  piecing  a  system  together  based  on 
units  currently  in  inventory  or  they  need  to  add  a  specific  capability  to  a  current  system. 

Adopt  a  current  standard 

Adopting  a  current  standard  requires  knowledge  of  standards  in  the  market.  This  alternative 
would  include  a  survey  of  current  message  structures  with  a  trade  study  to  choose  the  best  one. 
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While  selecting  a  standard  that  is  both  complete  and  in  use  would  be  the  preferred  method,  there 
are  few,  if  any,  standards  that  appear  to  meet  our  basic  requirement  of  handling  T&E  data.  The 
limiting  factor  with  this  approach  lies  with  the  highly  coupled  nature  of  the  message  structure  to 
the  application.  Data  acquisition  networks  are  a  new  and  specialized  niche.  Finding  ready  to  use 
message  structures,  while  desirable,  may  not  be  realistic. 

Adapt  a  current  standard 

The  purpose  of  adapting  a  standard  to  fit  a  specific  need  is  to  leverage  the  advantages  a 
commercial  standard  has  to  offer  -  e.g.  saving  the  cost  of  developing  the  standard  and  using  the 
existing  user  base  to  keep  unit  costs  down.  This  approach  can  work  well  if  the  resultant 
adaptation  is  a  subset  of  the  original.  The  new  standard  would  restrict  the  user  from  utilizing  all 
of  the  capabilities  of  the  commercial  components.  Once  unique  items  or  capabilities  are  added  to 
the  standard  that  excludes  the  use  of  the  existing  commercial  products,  a  new  standard  is 
effectively  being  written  and  the  next  alternative  would  apply. 

Write  a  new  standard 

This  alternative  is  contrary  to  the  trend  being  seen  in  DoD  standards  of  late.  With  interface 
standards  becoming  so  complex,  the  DoD  generally  can’t  afford,  in  many  senses  of  the  word,  to 
develop  their  own  standards.  The  trend  has  been  summarized  as  “Adopt,  Adapt,  Develop”. 
With  the  network  hardware  standards  this  has  been  a  good  approach.  However,  in  defining  the 
message  structure,  it  doesn’t  appear  as  important.  The  data  acquisition  units  must  acquire  the 
test  data  and  format  it  into  some  message  structure.  There  is  no  commercial  firmware  or 
software  that  can  be  leveraged  by  the  developer.  Code  must  be  written  regardless  of  the  use  of  a 
well-known  standard  or  not.  Similarly  at  the  ground  station  where  the  messages  get  processed, 
code  must  be  written  to  process  the  data.  Utilizing  an  existing  commercial  standard  does  not 
seem  to  carry  the  weight  for  this  project  as  it  has  for  previous  ones. 


Inter-Service  Cooperation 

As  data  acquisition  networks  gain  ground,  this  message  structure  will  become  as  well  known  to 
the  telemetry  community  as  the  IRIG  106  PCM  standards  are  today.  This  need  is  shared  by  all 
three  services  and  is  being  coordinated  through  the  Range  Commanders  Council  Telemetry 
Group  (RCC-TG). 


Potential  Areas  of  Study 

There  are  at  least  two  areas  of  study  this  project  should  address.  The  first  area  is  researching 
current  message  structures.  Two  message  structure  sources  come  to  mind.  The  first,  and 
potentially  more  desirable,  is  standards  produced  by  the  well-known  standards  organizations  like 
the  IEEE,  ANSI,  etc.  The  second  source,  and  potentially  more  useful,  is  other  programs  that 
may  have  similar  needs.  Though  an  exact  match  for  this  project  may  not  be  found,  a  lot  of  useful 
information  can  be  gleaned  from  both  of  these  sources.  One  of  the  more  available  examples  is 
the  EA  IFF  85  Interchange  File  Format.  This  is  what  the  WAV  sound  file  is  based  on.  The 
message  attributes  allow  the  computer  to  play  the  file  without  any  prior  knowledge  of  the  file  to 
be  known.  The  format  also  allows  many  other  types  to  be  defined  within  the  same  broad 
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structure.  The  second  area  of  study  is  the  requirements  drivers.  There  are  two  broad  sources  of 
requirements  -  the  data  acquisition  network  or  data  source  and  the  ground  station  or  data  sink. 

Constraints 

The  introduction  of  network  connectivity  into  the  telemetry  community  allows  many  new 
capabilities,  but  also  requires  the  community  to  look  beyond  its  borders.  The  long  view  of 
network  technology  is  that  the  network  on  the  test  article  will  be  connected  to  the  ground 
network  via  a  telemetry  network.  This  will  give  complete  network  connectivity  from  the  data 
being  acquired  on  the  test  article  to  the  user’s  desk.  Telemetry  data  can  then  be  fed  directly  to 
simulators  and  training  facilities  as  the  need  warrants.  Any  selection  or  development  of  a 
message  structure  must  therefore  take  this  big  picture  into  consideration. 
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